Компания VMware на днях выпустила обновления своих клиентов для управления виртуальной инфраструктурой - VMware vSphere Client 3.1 (бывший vSphere HTML5 Web Client - управление всей платформой vSphere) и ESXi Embedded Host Client 1.16 (управление отдельными хостами ESXi через веб-интерфейс).

Давайте посмотрим, что нового появилось в VMware vSphere Client 3.1 (о версии 3.0 мы писали вот тут):

• Представление Cluster > Monitor > Storage Overview, которое показывает данные о хранилище хостов в кластере в агрегированном виде. Теперь становится несложно понять, когда хост отличается от стандартной конфигурации кластера.
• Представление Host Cache Configuration в режиме read-only.
• Можно редактировать настройки исполнения Storage DRS и расширенные настройки (advanced settings).
• Поддержка перетаскивания виртуальной машины драгэнддропом в виртуальный датацентр.
• Поддержка перетаскивания шаблона виртуальной машины драгэнддропом в виртуальный датацентр или папку.
• Перетаскивание машины и шаблона работает из списка в дереве инвентори в центральной области.
• Удаление глобальных тэгов и категорий.
• Действие Mount/Unmount на странице VMFS > Configure > Connectivity and Multipathing.
• При создании новой ВМ есть опция клонирования существующей.
• При клонировании ВМ можно задать ее политику хранения.

А вот что нового в ESXi Embedded Host Client 1.16 (о версии 1.13 мы писали вот тут, версий 14 и 15 не было):

• Добавление RDM-дисков виртуальной машине!
• Решена проблема с удалением USB-устройств от ВМ.
• Добавлена возможность показа метрик отдельной ВМ на графиках производительности хоста.
• Обработка случайных двойных кликов в меню.
• Добавлена настройка шаринга виртуальных дисков.
• Поправлена ошибка в обновлении списка ВМ при применении фильтров.
• Обработка XML при развертывании из OVF-шаблона.
• Добавлен чекбокс, который позволяет не включать ВМ после создания (чтобы отредактировать настройки).
• Поправлены ошибки с настройками автостарта ВМ, SR-IOV и устройств PCI.
• Отображение информации Cisco Discovery Protocol на странице физического NIC. Там же показываются и обнаруженные подсети.

Скачать VMware vSphere Client 3.1 можно по этой ссылке, а ESXi Embedded Host Client 1.16 - по этой.

Иногда в виртуальной инфраструктуре VMware vSphere возникает необходимость скопировать большой объем данных с хоста VMware ESXi. Например, нужно что-то загрузить на изолированный от общей сети хост или забрать виртуальные машины на флешке для переезда на другую инфраструктуру. Через USB сделать это гораздо быстрее, чем ждать пока все это пройдет по небыстрой сети предприятия. Вильям Лам сделал на этот счет полезную инструкцию.

Скопировать файлы с и на ESXi можно как на USB-накопитель в формате FAT32, так и в формате NTFS. Но сначала надо остановить службу USB Arbitrator Service, которая отвечает за проброс USB-устройств в виртуальные машины (passthrough). Делается это следующей командой:

/etc/init.d/usbarbitrator stop

Теперь можно воткнуть флешку, убедиться, что она примонтировалась (она должна появиться в списке хранилищ по адресу /vmfs/volumes/) и выполнить следующую команду для копирования файла с USB-устройства в формате FAT32 на хост ESXi:

/bin/mcopy -i "/dev/disks/${USB_KEY}:2" ::/MyFile /tmp/MyFile

Обратите внимание, что адрес к USB-устройству надо указывать через /dev/disks/. /MyFile - это путь к файлу на флешке, а /tmp/MyFile - путь к размещению файла на ESXi.

Ну а вот так можно скопировать файл в обратную сторону - с хоста ESXi на USB-накопитель (просто меняем пути местами, путь с двумя двоеточиями - относится к флешке):

/bin/mcopy -i "/dev/disks/${USB_KEY}:2" /tmp/MyFile ::/MyFile

Минус тут в том, что для FAT32 размер файла на USB-устройстве может быть не более 4 ГБ, поэтому для перемещения виртуальной машины ее диск придется разбить на кусочки. Для этого в Linux и Mac OS существует следующая команда (размер кусочка указывается в байтах, в данном случае - 1 ГБ):

split -b 1073741824 [FILE-TO-BE-SPLIT]

После того, как файлы будут перемещены, их можно склеить следующей командой, указав имена кусочков через *:

cat [SPLITTED-FILES]* > [ORIGINAL-FILE-NAME]

Для файловой системы NTFS можно воспользоваться утилитой ntfscat для копирования файлов. Если вы хотите скопировать файл с USB-устройства на хост ESXi нужно выполнить следующую команду:

/bin/ntfscat -f /dev/disks/${USB_KEY}:2 MyFile > /tmp/MyFile

Многие наши читатели заметили, что мы часто пишем про решение VMware vCenter Server Appliance (например, тут, тут и тут) - готовый виртуальный модуль на основе Linux для управления виртуальной инфраструктурой VMware vSphere. Также мы иногда пишем и про VMware Feature Walkthroughs (например, тут, тут и тут) - интерактивные обзоры интерфейсов продуктов, где можно узнать о возможностях различных решений VMware и самому потыкать кнопки и менюшки.

Ну а сегодняшняя новость, как следует из сказанного выше, о том, что появились новые Walkthroughs, посвященные развертыванию модуля VMware vCenter Server Appliance.

Установщик VCSA 6.5 больше не требует предварительного наличия Client Integration Plugin (CIP), поэтому все начинает ставиться сразу же. Плагин Enhanced Authentication Plugin (EAP) вам понадобится только, если вы будете использовать аутентификацию Windows Authentication (SSPI) или Smart Card Authentication.

Сам установщик может выполнять следующие функции:

• Экспорт виртуальной машины или объекта vApp в формате OVF/OVA.
• Развертывание виртуального модуля OVF/OVA с локального диска или по URL.
• Экспорт из Content Library на локальный диск.
• Загрузка файлов из датастора и закачка на него.
• Присоединение устройств к виртуальной машине (CD-ROM, USB и т.п.).

Для виртуального модуля vCSA 6.0 был один процесс развертывания - и если происходила какая-то ошибка, его приходилось начинать заново. У vCSA 6.5 есть два этапа развертывания, каждый из которых не зависит от первого.

На стадии Stage 1 происходит развертывание модуля OVA, настройка простейшего сетевого взаимодействия и запуск сервисов VMware vSphere Appliance Management Interface (VAMI). Это позволяет вторую часть уже проводить позже, через интерфейс VAMI.

На этапе Stage 2 происходит окончательная конфигурация виртуального модуля и применение настроек непосредственно внутри vCSA. Это, кстати, позволяет снять снапшот между фазами - на случай если что-то пойдет не так во второй фазе.

Также интересная штука - появился тип развертывания "X-Large" - в такой установке vCSA может управлять до 2000 хостов VMware ESXi и до 35000 виртуальных машин. Это подразумевает увеличенный размер для хранилища Stats, Events, Alarms, and Tasks (SEAT).

Ну и, собственно, сами Walkthroughs вы найдете по ссылкам ниже:

• vCenter Server Appliance Embedded Deployment Walkthrough (развертывание всех необходимых компонентов на одной виртуальной машине).
• vCenter Server Appliance External Deployment Walkthrough (в этом случае Center Server и сервисы Platform Services Controller будут в разных ВМ).

Как вы знаете, не так давно компания VMware выпустила обновление платформы виртуализации vSphere 6.5, где появилась масса новых возможностей, среди которых были также и улучшения механизма обеспечения высокой доступности VMware HA.

На днях появилось интересное видео, подробно объясняющее, в чем именно они заключаются:

Во-первых, приоритет рестарта виртуальных машин был расширен - вместо трех уровней (Low, Medium и High) появилось пять (добавились Lowest и Highest). Это позволит увеличить гранулярность приоритета запуска виртуальных машин при сбое, которой, видимо, хватало не всем:

Во-вторых, появились возможности восстановления виртуальных машин с учетом связи сервисов в ВМ между собой. Теперь VMware HA позволяет учитывать взаимосвязи сервисов в виртуальных машинах при их рестарте в случае сбоя на основе заданных правил зависимостей VM-to-VM по приоритетам восстановления.

Например, в VM1 у нас размещена база данных, в VM2 и VM3 - серверы приложений с зависимостью, а в VM4 - балансировщик, который должен подняться в последнюю очередь, чтобы цепочка сервисов за ним способна была предоставлять услуги пользователям.

Посмотрите на картинку - для такой конфигурации, если первый хост-сервер выйдет из строя, то VM2 запустится только после того, как будет запущена VM1, что обеспечит работоспособность сервиса и не навредит приложениям.

А вот если выйдет из строя третий хост ESXi - то VM5 и VM7 могут запуститься одновременно, согласно правилу во второй строчке (VM5<-VM6<-VM7<-VM8), так как для VM5 нет предварительного условия старта, а для VM7 условие старта выполнено - машина VM6 работает. Поэтому в данном случае добавляется еще одно правило VM5<-VM7. Имейте это в виду при планировании виртуальной инфраструктуры и кластеров HA.

Настраиваются такие правила довольно просто. Сначала в интерфейсе настройки VMware HA мы создаем несколько групп VM/Host Group, в каждую из которых добавляем только по одной виртуальной машине:

А далее устанавливаем правила (VM/Host Rules) типа "Virtual Machines to Virtual Machines" для данных групп, где определяем, какую ВМ нужно запускать сначала, а какую вслед за ней.

Определив нужный набор этих правил, мы можем реализовать любую конфигурацию последовательности перезапуска виртуальных машин в случае сбоя, в зависимости от условий рестарта/работоспособности зависимых сервисов.

Недавно компания VMware выпустила очередной интересный технический документ "VMware vSphere encrypted vMotion architecture, performance, and best practices", посвященный различным аспектам работы механизма шифрованной миграции виртуальных машин между хостами.

Напомним, что шифрование как данных виртуальных машин, так и трафика vMotion, появилось в обновленной версии платформы VMware vSphere 6.5. Шифрование трафика vMotion происходит на уровне VMkernel средствами широко распространенного алгоритма AES-GCM (Advanced Encryption Standard / Galois Counter Mode).

Эксперименты, описанные в открытом документе, подтвердили следующее:

• Миграция vSphere 6.5 Encrypted vMotion работает практически с той же скоростью, что и vMotion.
• Нагрузка на CPU для шифрования небольшая за счет оптимизации в коде реализации vMotion.
• vSphere 6.5 Encrypted vMotion работает так же надежно, как и обычный vMotion.

Миграция в корпоративной инфраструктуры виртуальной машины с СУБД Redis:

Миграция виртуальной машины SQL Server на длинную дистанцию при различных задержках в канале, зависящих от удаленности датацентров:

Содержание документа:

• Encrypted vMotion Architecture
  • Encryption Protocol
  • Encryption Algorithms
  • Defending Against Replays
  • Workflow
• Encrypted vMotion Configuration
• Performance Test Configuration and Methodology
  • Test Configuration
  • Measuring Encrypted vMotion Performance
• Encrypted vMotion Performance in a Private Cloud Deployment
  • Performance Impact on Duration and Switch-Over Time
  • Performance Impact on Throughput and CPU Usage
• Encrypted vMotion Performance Over Long Distance
  • Test Methodology
  • Load Generation Software
  • Results
• Encrypted vMotion Performance Best Practices

Кстати, шифрованные виртуальные машины всегда перемещаются между хостами ESXi средствами также шифрованного vMotion.

PowerShell функция Connect-VMHostPutty из моего PowerCLI Vi-Module модуля поможет вам открывать несколько SSH-сессий putty к хостам ESXi без ввода пароля. Функция на самом деле не требует, чтобы на вашем компьютере был установлен VMware PowerCLI. Всё, что нужно - это PowerShell версии 3.0 или выше. Это очень короткая и простая функция всего с двумя параметрами и только один из них обязательный...

Некоторые из вас знают, что в VMware vSphere есть механизм удаленного сбора дампов с серверов VMware ESXi, которые иногда выпадают в "розовый экран смерти" с диагностической информацией в случае критической ошибки.

Для сбора диагностической информации используется специальная служба ESXi dump collector service, которая принимает дамп хост-сервера по сети. Но сначала эту службу надо включить на сервере VMware vCenter (в частности, на vCenter Server Appliance). Для этого надо в vSphere Web Client пойти сюда:

Home > Administration > System Configuration > Services > VMware vSphere ESXi Dump Collector > Start

Кроме этого, нужно задать порт для приема дампов, а также надо сконфигурировать максимальный размер репозитория в гигабайтах, задав параметр Repository max size.

Теперь надо сконфигурировать параметры отправки кордампов через сеть на хостах ESXi. Сначала выполним следующую команду для проверки текущего статуса:

esxcli system coredump network get

Зададим сетевые параметры отправки дампов :

esxcli system coredump network set -- interface -name vmk0 -- server -ipv4 172.20.10.94 --server -port 6500

И включим службу сбора дампов:

esxcli system coredump network set --enable true

Проверим параметры отправки:

Теперь можно выполнить следующую команду для проверки параметров:

esxcli system coredump network check

Теперь, чтобы проверить, что vCenter Server Appliance принимает дампы, надо открыть следующий файл:

/var/log/vmware/netdumper/netdumper.log

Мы увидим там примерно следующую картину:

Теперь принудительно отправим ESXi в розовый экран командой CrashMe и заглянем в этот же файл еще раз:

Мы видим, что теперь появилась запись о дампе var/core/netdumps/ffff/172/20/10/52/zdump_ffff.172.20.10.52-2017-01-05-09_53-0. Откроем этот файл и увидим содержание дампа, появляющегося при крэше ESXi:

До выхода новой версии платформы виртуализации VMware vSphere 6.5, механизмы AutoDeploy и Image Builder можно было использовать только с консольным фреймворком PowerCLI. Теперь же у Image Builder / AutoDeploy появилось собственное GUI в vSphere Web Client, с помощью которого можно удобно создавать кастомные образы VMware ESXi.

Но сначала нужно включить службу ImageBuilder Service. Для этого в веб-клиенте идем в Administration -> System Configuration -> Services > выбираем ImageBuilder Service и из меню Actions выбираем Start. После этого Image Builder будет доступен для использования:

Слева есть менюшка Auto Deploy:

Выбираем ее:

На вкладке Software Depots добавляем новый Depot:

Импортируем в него образ VMware ESXi:

Например, VMware-ESXi-6.5.0-4564106-depot.zip (оригинальный образ ESXi 6.5)... Читать статью далее

Многие из вас читали, что в новой версии VMware vSphere 6.5 появилась экспериментальная поддержка механизма Predictive DRS, который проактивно предпринимает действия по выравниванию нагрузки виртуальных машин на хосты ESXi, еще до того, как эта нагрузка придет.

Посмотрим как раньше работал VMware Distributed Resource Scheduler (DRS):

Работал он реактивно (Reactive) - то есть, когда нагрузка пошла, только тогда включался механизм ее выравнивания. При этом пользователи во время этого процесса могут испытывать неудобства из-за миграций vMotion между хостами и, собственно, самой резко растущей нагрузки (например, весь отдел вернулся с обеда). В этом случае происходит миграция только необходимого числа машин, чтобы выровнять основные показатели нагрузки.

Поэтому появился сбалансированный метод (Balanced). В этом случае DRS старается поддерживать баланс по нагрузке на хосты кластера (или даже между кластерами), чтобы не было перекосов в ту или другую сторону. Работает этот метод совместно с продуктом vRealize Operations (vROps), который собирает метрики с хостов и старается поддерживать баланс в виртуальном датацентре:

Этот алгоритм пытается сгладить углы резко изменяющейся нагрузки, но требует серьезных вычислений на стороне vROps и, как мы видим из картинки, не дает никаких гарантий.

Поэтому в VMware решили применить другой подход - Predictive DRS. Суть этого метода проста - компонент vROps ежедневно собирает сотни различных метрик со всех объектов виртуального датацентра (хосты, ВМ, хранилища). Эти метрики "обучают" механизм vROps, который каждую ночь анализирует данные о производительности хостов и формирует так называемые Dynamic Thresholds:

Predictive DRS производит очень сложный анализ на основе 10 различных алгоритмов и формирует коридор производительности "нормального" поведения виртуальных машин (обозначен на картинке серым). Границы этого коридора и есть Dynamic Thresholds, при выходе за границы которых в данное время, поведение в кластере считается аномальным. Работает этот механизм на уровне каждой виртуальной машины.

И тут самое интересное - Predictive DRS позволяет заранее понять, что на таких-то хостах виртуальные машины будут биться за ресурсы через некоторое время, и проактивно начинает мигрировать виртуальные машины, готовясь к ситуации изменения нагрузки:

То есть, синяя линия - это то, как будет (а точнее, как обычно было раньше - ведь так, скорее всего, будет и сегодня), а вот красная линия - это то, что подается на вход обычного DRS, чтобы он заранее начинал действия по подготовке ко всплеску нагрузки, который произойдет через некоторое время (например, бухгалтерия придет к 9-00 и будет включать свои виртуальные десктопы). В этот момент их, например, можно поддержать простаивающими хостами ESXi, где хостятся десктопы ленивых менеджеров, приходящих к 11 утра.

Ну а какой метод нужно использовать? VMware рекомендует использовать все три, в зависимости от ситуации:

Ну и отметим, что этот функционал доступен только в рамках решения vRealize Operations, о котором также можно почитать вот тут.

Если вы работаете с хостом VMware ESXi через "толстый" клиент vSphere Client, бывает такая ситуация, что его консоль показывает неполный экран гостевой ОС виртуальной машины.

Выглядит это примерно так:

Особенно часто это бывает, если ОС у вас, где вы запускаете клиент - Windows 10. Чтобы поправить эту ситуацию, нужно сделать следующее:

• Кликнуть на иконке vSphere Client и выбрать Properties (Свойства).
• Выбрать раздел Compatibility (Совместимость).
• Отметить чекбокс Disable display scaling on high DPI Settings (Отключить масштабирование изображения при высоком разрешении экрана).

После этого нужно перезапустить сессию vSphere Client - и все заработает как нужно!

Недавно мы писали о новых возможностях VMware vSphere 6.5, где, в частности, мы рассказывали о том, что VMware vSphere Update Manager 6.5 (VUM) теперь интегрирован с vCenter Server Appliance (vCSA). Но надо отметить, что VUM теперь не просто интегрирован, а является неотъемлемой частью vCSA, что делает его очень удобным в использовании.

Его не нужно устанавливать, его можно сразу же начать применять для обновлений хостов ESXi, виртуальных машин и виртуальных модулей (Virtual Appliances):

Пройти все шаги по обновлению хостов ESXi кластера VMware HA/DRS с помощью Update Manager можно в специальном кликабельном демо (feature walkthrough) - "vSphere Update Manager Overview & Cluster Upgrade".

Давайте пройдем этот процесс по шагам:

1. Кликнем на вкладку Update Manager в vSphere Client:

2. Здесь мы видим основное представление Update Manager. Нажимаем кнопку "Go to Admin View":

3. Мы видим настройки механизма Update Manager.

Первым делом нужно будет создать базовый уровень по обновлениям хоста ESXi (Host baseline). Идем в раздел Host Baselines....читать статью далее ->>

Мы уже много писали о новых возможностях обновленной версии платформы виртуализации VMware vSphere 6.5, а сегодня расскажем еще об одной - улучшениях механизма vSphere Host Profiles.

Напомним, что vSphere Host Profiles позволяют управлять конфигурациями хост-серверов VMware ESXi за счет создания эталонных профилей хостов, которые затем можно применить на хосты, нуждающиеся в приведении к заданным настройкам.

В VMware vSphere 6.5 в механизм Host Profiles были добавлены следующие возможности (по ссылкам можно опробовать их в виде Product Walkthroughs - то есть пошаговых гайдов на примере реального интерфейса продукта):

1. Host Profiles – Granular Compliance Results

До vSphere 6.5 результатом сравнения профиля хоста с актуальными настройками на ESXi был отчет о том, какие параметры не соответствуют, но не было сравнения side-by-side - чтобы наглядно видеть актуальные и желаемые настройки. Теперь это показано в едином представлении (Host value и Host profile value):

2. Host Profiles – Batch Host Customization

В кластере, как правило, хосты настроены единообразно. Однако иногда необходимо на конкретном хосте сделать особенные настройки, которые называются host customizations (ранее это были answer files). Теперь их можно экспортировать в формате CSV в отдельные файлы и редактировать их офлайн, а потом залить обратно в Host Profiles.

3. Host Profiles – Create, Edit & Copy Settings

Графический процесс создания и редактирования профилей хостов был существенно улучшен. Кроме того, появилась возможность копирования между профилями хостов, что очень удобно при изменении одной настройки, которую надо отреплицировать во все профили. Также это позволяет создавать иерархию профилей, по которой должны спускаться некоторые настройки (например, пароль root).

Ну и напоследок - обучающее видео, в котором показаны возможности vSphere Host Profiles 6.5:

Недавно мы писали о том, что некоторое время назад компания VMware выпустила окончательную релизную версию VMware vSphere HTML5 Web Client (он же сейчас называется просто vSphere Client), а на днях VMware зарелизила и финальную версию клиента для управления отдельными хост-серверами через браузер - VMware ESXi Embedded Host Client 1.13.

Теперь Embedded Host Client будет входить в состав VMware ESXi 5.5, ESXi 6.0 и ESXi 6.5, о чем есть соответствующая пометка на VMware Labs (напомним, он распространяется в виде VIB-пакета). Далее апдейты клиентов будут выходить, как и прежде, на страничке в Labs.

Последний раз мы писали о версии ESXi Embedded Host Client 1.10 - давайте посмотрим, что нового появилось в этом средстве с тех пор:

• Поддержка удаления USB-контроллеров из ВМ
• Обновление метрик хранилищ при загрузке и обновлении страницы Summary
• Нотификация на странице Summary, когда у хоста истекла лицензия
• Улучшенное отображение информации от Hardware sensors, также появилось время их последнего обновления
• Ссылка на имя хоста/IP-адрес в списке ВМ, а также в заголовке VM Summary
• Пофикшены вылеты в IE 10
• Обновлены средства локализации (русского, традиционно, нет)
• Улучшено отображение графиков производительности сети
• Показ ошибки при попытке загрузить файл более 4 ГБ на датастор (IE)
• Игнорирование отсутствующих датасторов, например, недоступных NFS-дисков
• При генерации саппорт-бандла с диагностической информацией - сессия не отваливается
• В разделе Host -> Monitor -> Hardware появилась информация о состоянии хоста (Hardware health)
• Hardware sensors теперь могут быть упорядочены по состоянию, то есть красные - в самом верху списка
• Новые раскладки клавиатуры в консоли (French, Swiss-French, Swiss-German)
• Добавлены датасторы в список ВМ на хосте
• Добавлена поддержка pre-defined OVF-свойств в мастер развертывания OVA-модулей
• Поправлена ошибка редактирования CD-ROM, когда его нет в наличии на хосте
• Поправлены баги при сохранении настроек Host Client
• Поправлены вылеты в VM editor в Safari
• Поправлена ошибка с обновлением страницы Physical NIC summary
• Несколько других минорных исправлений

Скачать VMware ESXi Embedded Host Client 1.13 можно по этой ссылке.

Недавно мы писали об основных новых возможностях VMware vSphere 6.5, среди которых не упомянули о том, что в новой версии платформы теперь полностью поддерживается репликация томов VVols. Именно отсутствие репликации было для многих критичным фактором, препятствующим внедрению VVols 2.0 в производственных средах. Об репликации VVols 2.0 мы уже подробно рассказывали вот тут.

Репликация стала возможной благодаря обновленному интерфейсу APIs for Storage Awareness (VASA) версии 3.0. VASA 3.0 предоставляет компоненты политик движка SPBM, который позволяет скомбинировать политику VVol и фильтр интерфейса VAIO Filter, для которого могут предоставляться такие сервисы, как шифрование (VMCrypt), репликация или кэширование от сторонних производителей программного и аппаратного обеспечения.

Попросту говоря, за счет API VASA и VAIO можно поддерживать различные функции VVols на базе хранилищ, а со стороны хостов ESXi предоставлять различные сервисы, обеспечиваемые фильтрами, для виртуальных машин на базе политик SPBM.

Совсем скоро эти возможности будут поддерживаться в Nimble и HPE 3PAR, а впоследствии будут доступны и у других вендоров.

Напомним, что с VVols 2.0 можно реплицировать не весь том VMFS целиком, а отдельную виртуальную машину (и даже отдельные виртуальные диски). Также несколько ВМ можно реплицировать в рамках одной Replication Group (при этом сразу в несколько географически разнесенных локаций).

Кроме того, уже доступны командлеты PowerCLI для управления репликацией на базе VVols (Get-SpbmReplicationPair, Start-SpbmReplicationFailover, Sync-SpbmReplicationGroup и прочие).

Недавно мы писали о новых возможностях VMware vSphere 6.5, где упомянули, что VMware vSphere HTML5 Web Client, о котором мы много писали, еще не совсем функционален, а потому не может быть рекомендован к использованию в производственной среде.

Между тем, на сайте VMware Labs, где выкладываются регулярные обновления клиента, появился апдейт с важной информацией о том, что теперь VMware vSphere HTML5 Web Client полностью вышел в релиз, а сам клиент называется теперь vSphere Client (и поставляется в составе vSphere 6.5 и выше).

Текущая версия vSphere Client - это 2.16, а мы писали про 2.8, поэтому приведем здесь вкратце новые возможности последних версий (2.9, 2.10, 2.11, 2.12, 2.13, 2.14, 2.15 и 2.16), которые вместе уже и составляют полноценный спектр возможностей нового веб-клиента vSphere.

• Настройка параметров CHAP для iSCSI-адаптеров
• Детали сети для привязки портов Software iSCSI и полное редактирование настроек
• Включение/выключение логгирования для ВМ в настройках
• Изменение свойств и политик стандартных порт-групп коммутаторов
• Хосты могут быть передвинуты в инвентори драг энд дропом
• Удаление нескольких ВМ с диска
• Удаление шаблонов ВМ с диска
• Действие Upload Folder в File Browser (доступно только для Chrome, Edge и Firefox 50 и выше)
• Возможность задать тип сети в настройках ВМ
• Портлеты на странице Summary можно перемещать драг энд дропом
• Действие Upgrade to VMFS5
• Диаграмма Partition Layout в разделе создания датастора и при увеличении датастора
• Монтирование/размонтирования хранилищ NFS
• Просмотр, редактирование свойств и политик Distributed Port Groups
• Добавление/удаление физических адаптеров и порт групп для Standard или Distributed Switch
• Редактирование и просмотр свойств и политик стандартного коммутатора
• Графики производительности можно открыть в новом окне
• Можно создавать и удалять кластеры хранилищ
• Возможность включить проброс (passthrough) для устройств ESXi PCI
• Можно смотреть использование GPU серверов ESXi
• Настройки Storage I/O Control
• Возможность привязки/отвязки устройств на странице Host Storage Devices
• Конвертирование и клонирование ВМ в шаблон
• Создание датасторов NFS3 / NFS4.1 (в том числе, в режиме Read-only)
• Управление политиками доступа по нескольким путям (Multipathing)
• Монтирование/размонтирование томов VMFS
• Горячие клавиши для операций с питанием ВМ
• Rescan storage (новых томов VMFS и устройств)
• Детали разделов в Host > Configure > Storage Devices
• Детали устройств в Datastore > Configure > Device Backing
• Управление Lockdown mode для ESXi
• Хосты ESXi можно присоединить к домену
• Полное управление тэгами

Скачать vSphere Client можно по этой ссылке. Также он доступен в составе дистрибутива vSphere 6.5.

Вместе с новой версией платформы VMware vSphere 6.5 компания VMware выпустила также и обновления своих интерфейсов командной строки. О новых возможностях VMware PowerCLI 6.5 мы уже писали, а в этой заметке расскажем о командном интерфейсе ESXi - vSphere Command-Line Interface (vCLI) 6.5.

Напомним, что vCLI позволяет выполнять консольные команды, которые также доступны и через виртуальный модуль vSphere Management Assistant (vMA), на серверах VMware ESXi из системы с различными ОС.

Интерфейс ESXCLI

С точки зрения интерфейса ESXCLI появились возможности управления FCOE-адаптерами, настройками NIC queuing и coalescence, параметрами проброса USB pass-through, обработка управления устройствами NVMe, а также управления конфигурациями vSAN iSCSI.

Вот примеры исполнения этих команд:

  
esxcli device driver list
  
esxcli fcoe adapter remove
  
esxcli fcoe nic enable
  
esxcli graphics device stats list
  
esxcli graphics host get
  
esxcli hardware usb passthrough device enable
  
esxcli hardware usb passthrough device list
  
esxcli network multicast group list
  
esxcli network nic queue filterclass list
  
esxcli network nic queue loadbalancer list
  
esxcli nvme device list
  
esxcli nvme device firmware activate
  
esxcli nvme device firmware download
  
esxcli nvme device log error get
  
esxcli software vib signature verify
  
esxcli storage vmfs reclaim config get
  
esxcli system coredump vsan get
  
esxcli system wbem get
  
esxcli vsan iscsi homeobject get
  
esxcli vsan iscsi status get

Интерфейс Datacenter CLI

Также появились и улучшения интерфейса Datacenter CLI (DCLI), который позволяет управлять глобальными сущностями виртуального датацентра. Теперь доступны команды для мониторинга и управления виртуальным модулем vCSA в различных аспектах, таких как сетевое взаимодействие, статус модуля, доступ, выполнение операций резервного копирования и восстановления, а также просмотр параметров аптайма и версии. Кроме того, есть функции для сбора информации об окружении vCenter - датацентрах, сетях, папках, хостах, кластерах и прочем. Ну и появились функции для управления жизненным циклом ВМ.

Вот некоторые примеры:

  
appliance monitoring
  
appliance vmon service
  
appliance networking interfaces
  
appliance networking dns servers
  
appliance health load
  
appliance health system
  
appliance health storage
  
appliance health softwarepackages
  
appliance access ssh
  
appliance recovery backup
  
appliance recovery restore
  
appliance system uptime
  
appliance system version
  
vcenter datacenter
  
vcenter network
  
vcenter folder
  
vcenter vm hardware
  
vcenter vm power
  
vcenter vm hardware memory
  
vcenter vm hardware cpu

Все работает с интерактивными подсказками:

Улучшения поддержки ОС

Теперь была добавлена поддержка следующий операционных систем:

• Ubuntu 15.10 (LTS) – 64-bit
• Ubuntu 16.04 (LTS) – 64-bit
• Windows 10 (64-bit)

Для Windows-систем вам потребуется наличие ActivePerl или Strawberry Perl версии 5.14.

Для получения более детальной информации о vCLI можно почитать Release Notes. Также будет полезен раздел документации о vSphere CLI 6.5 с примерами. Есть еще очень полезная вещь vSphere CLI Reference.

Скачать vSphere vCLI 6.5 для Windows или Linux можно по этой ссылке.

На днях компания VMware выпустила интереснейший технический документ обо всех новых возможностях новой версии своей флагманской платформы виртуализации - "What’s New in VMware vSphere 65".

Напомним, что о новых возможностях VMware vSphere 6.5 мы уже писали вот тут. Также можно посмотреть наши заметки тут, тут и тут. А вот содержание документа:

• VMware vCenter Server
  • Migration
  • Improved Appliance Management
  • VMware vCenter High Availability
  • Backup and Restore
  • vSphere Web Client
  • vSphere Client
• vSphere Host Lifecycle Management Enhancements
  • vSphere Update Manager
    • VMware Tools and Virtual Hardware Upgrades
    • Previous Windows-Based Architecture Still Offered
  • Host Profiles
    • Profile Management Improvements
    • Operational Enhancements
  • Auto Deploy
    • Manageability Improvements
    • Performance and Resiliency Enhancements
  • VMware Tools 10.1 and 10.0.12
    • Signed ISO Images
    • Bifurcation of VMware Tools for Legacy and Current Guests
    • Bundling of Tools for Most Popular Guests Only
    • Guest OS Granularity Increase
    • Detailed Display of VMware Tools Type and Version in vSphere Web Client
    • Improved Detection of Availability of Updated VMware Tools Installers
• vSphere Operations
  • Operations Management
  • Log Monitoring
• Developer and Automation Interfaces
  
  • Program Interfaces
  • vCenter Server Appliance API
  • Virtual Machine API
  • Discover the APIs with the New API Explorer
  • Process Improvements
  • Command-Line Interfaces
  • What’s New in VMware vSphere
  • VMware PowerCLI
    • Core vSphere Module
    • Storage Module
    • VMware Horizon Module
• Security
  • Virtual Machine Encryption
    • Encrypted vMotion
  • Secure Boot Support
    • Virtual Machine Secure Boot
    • ESXi Host Secure Boot
  • Enhanced Logging
  • VM Sandboxing
  • Automation
• vSphere 65 Availability Enhancements
  • Proactive HA
  • VMware vSphere High Availability Orchestrated Restart
  • vSphere HA Admission Control Improvements
  • VMware vSphere Fault Tolerance
  • Resource Management Enhancements
    • Improved vSphere DRS Load Balancing Algorithm
    • vSphere DRS Additional Options
    • Network-Aware vSphere DRS
    • VMware vSphere Storage I/O Control Using
      • Storage Policy Based Management
    • Content Library
  • vSphere Integrated Containers
• vSphere 65 Storage Enhancements
  • Advanced Format Drives and 512e Mode
  • Automated UNMAP
  • LUN Scalability
  • NFS 4.1 Support
  • Software iSCSI Static Routing Support
• vSphere 6.5 Networking Enhancements
• Enhancements for Nested ESXi
• Dedicated Gateways for VMkernel Network Adapter
• SR-IOV Provisioning
• Support for ERSPAN
• Improvements in DATAPATH

Мы уже немало писали о платформе виртуализации VMware vSphere 6.5, которая стала доступна для загрузки недавно. Оказывается известный блоггер Вильям Лам регулярно создает и поддерживает готовый виртуальный модуль на базе ESXi, а недавно он обновил его до последней версии платформы - VMware ESXi 6.5 Virtual Appliance.

Этот виртуальный модуль в формате OVA создан для того, чтобы развернуть хост-серверы ESXi в виде виртуальных машин на платформе vSphere в целях обучения и тестирования. Помните, что VMware не поддерживает вложенную (nested) виртуализацию в производственной среде.

Вот конфигурация виртуального модуля:

• GuestType: ESXi 6.5[новое]
• Virtual Hardware 11 [новое]
• 2 vCPU
• 6 GB памяти
• 2 x VMXNET vNIC
• 1 x PVSCSI Adapter [новое]
• 1 x 2GB HDD (под установку самого ESXi)
• 1 x 4GB SSD (для использования с vSAN, по умолчанию пустой)
• 1 x 8GB SSD (для использования с vSAN, по умолчанию пустой)
• Добавлены параметр VHV (подробнее)
• Добавлены параметры dvFilter Mac Learn в VMX-файл (подробнее)
• Добавлены параметр disk.enableUUID в VMX-файл
• VSAN-трафик тэгируется на интерфейсе vmk0
• Отключенный VSAN device monitoring для целей тестирования (подробнее)
• При создании нового тома VMFS будет использоваться новая версия VMFS 6 [новое]
• Включенный sparse swap (подробнее) [новое]

Для запуска виртуального ESXi 6.5 вам потребуется как минимум VMware vSphere 6.0 Update 2. Кстати, а вот какие улучшения появились для виртуального ESXi, которые можно опробовать в версии 6.5:

• Поддержка Paravirtual SCSI (PVSCSI)
• GuestOS Customization
• Поддержка ESXi 6.5 со стороны vSphere 6.0 Update 2
• Поддержка Virtual NVMe

Скачать виртуальный модуль VMware ESXi 6.5 Virtual Appliance можно по этой ссылке.

Недавно компания VMware выпустила новую версию платформы vSphere 6.5, о новых возможностях которой мы писали вот тут. Между тем, в плане хранилищ было сделано несколько важных улучшений, которые заслуживают отдельного поста. Большинство из этого реализуемо только на базе файловой системы VMFS 6.0, которая также появилась в vSphere 6.5.

1. Возврат дискового пространства хранилищу (Storage UNMAP).

Эта возможность была еще в VMware ESXi 5.0, но пропала по некоторым техническим причинам в следующих версиях. Теперь она полноценно была реализована в двух вариантах:

• Automatic UNMAP
• Поддержка Linux-based In-Guest UNMAP

Automatic UNMAP - это возврат дискового пространства виртуальной машины (ее VMDK) на сторону дискового массива средствами VAAI (vStorage API for Array Integration). Если раньше эта возможность требовала выполнения различных команд, то теперь управление этой штукой доступно из GUI, а возврат дисковых блоков происходит автоматически.

Для работы этой возможности вам понадобятся:

• ESXi 6.5+
• vCenter 6.5+
• VMFS 6
• Дисковый массив с поддержкой UNMAP

Если мы в настройках хранилища откроем вкладку Configure:

И далее нажмем Edit в разделе Space Reclamation Priority, то мы увидим вот такую настройку:

Здесь устанавливается приоритет, в соответствии с которым свободные блоки будут автоматически возвращены к LUN. Надо понимать, что UNMAP - это асинхронный процесс, который выполняет специальный crawler, потому и задается его приоритет. Понятное дело, что если задать высокий приоритет, то создастся дополнительная нагрузка на хранилища.

Кстати, для немедленного возврата дискового пространства можно воспользоваться командой esxcli storage vmfs unmap.

Поддержка Linux-based In-Guest UNMAP в vSphere 6.5 появилась впервые. Для ее работы нужна поддержка со стороны гостевой ОС Linux и ее файловой системы. Ну и работает это все только для тонких (thin) дисков.

Работает она не полностью автоматически, а запустить ее можно тремя способами:

1. Смонтировать файловую систему с опцией discard. Это будет возвращать простраство автоматически, когда будут удаляться файлы.
2. Выполнение команды sg_unmap. Это запустит механизм UNMAP для выбранных LBA.
3. Выполнение fstrim. Это вызовет команды trim, которые ESXi конвертирует в операции механизма UNMAP на уровне слоя vSCSI.

2. Функция Thin Hot Extend.

Это очень полезная штука была несколько ранее - она позволяла на горячую увеличить размер тонкого диска.

Вся загвоздка была в том, что диск можно было увеличить только до 2 ТБ, иначе возникала вот такая ошибка:

Теперь же можно задавать виртуальный диск любого размера.

3. Поддержка 4K-дисков в режиме 512e.

Теперь расширенный формат дисковых устройств 4K поддерживается со стороны vSphere 6.5, однако в режиме эмуляции 512e (то есть для 4к-девайсов эмулируются 512-байтные сектора). Такая же поддержка есть и в VMware Virtual SAN 6.5.

Полная поддержка 4k-устройств в нативном режиме ожидается в ближайшем будущем.

4. Поддержка до 512 устройств и 2000 путей.

Ранее платформа vSphere поддерживала 256 устройств и 1024 пути к одному хранилищу. И некоторые умудрялись упираться в лимиты, поэтому для таких клиентов и было сделано увеличение максимумов.

5. Увеличение лимита CBRC (он же View Storage Accelerator).

Про механизм кэширования Content Based Read Cache (CBRC) мы писали вот тут. Он позволяет увеличить производительность операций чтения для наиболее часто читаемых блоков виртуальных ПК за счет кэширования в оперативной памяти хоста VMware ESXi.

Ранее он был ограничен объемом в 2 ГБ, а теперь увеличился до 32 ГБ:

6. Переподписка проблемных томов (unresolved volumes resignaturing).

Теперь в vSphere 6.5 есть механизм для переподписки так называемых unresolved volumes, то есть томов, которые отвязались от основного по каким-то причинам, и теперь их метаданные являются не соответствующими текущей структуре файловой системы. Так, например, бывает в процессе резервного копирования, когда остается какой-нибудь повисший на диске снапшот, который не видно из GUI клиента vSphere.

В этом плане была проделана существенная работа и сделано множество улучшений, о которых можно прочитать тут.

Это основные, но не все улучшения VMware vSphere 6.5 в плане хранилищ, а если хочется узнать обо всех, то почитайте документ "vSphere 6.5 Storage", где очень много всего интересного.

Некоторое время назад мы писали о бесплатном продукте StarWind V2V Converter, который позволяет просто и удобно конвертировать виртуальные машины и их диски между любыми форматами платформ виртуализации.

Между тем, совсем недавно компания StarWind выпустила обновление этого замечательного средства, в котором были добавлены следующие возможности:

• Возможность конвертировать VMDK-файлы напрямую на сервер VMware ESXi, что отменяет необходимость использовать какую-то локальную машину, а потом закидывать полученную ВМ на хранилище хост-сервера.
• Также появилась возможность забирать файлы VHD/VHDX напрямую с Windows Hyper-V Server, а также конвертировать машину на целевой сервер Hyper-V. Теперь нет необходимости использовать локальную машину в качестве промежуточного звена, как для исходной машины, так и для целевого сервера.

Нововведения эти весьма существенные, так как теперь все конвертации между форматами VMware ESXi и Microsoft Hyper-V вы теперь можете проводить напрямую, не задействуя промежуточную машину, что экономит время и ресурсы.

Скачать бесплатный продукт StarWind V2V Converter можно по этой ссылке.

Недавно мы писали об обновленных максимумах конфигурации VMware vSphere 6.5, которые изменились в целом несущественно. В новой версии платформы также обновится и версия виртуального аппаратного обеспечения - теперь виртуальные машины будут иметь VMware Virtual Hardware Version 13.

В таблице ниже можно наглядно увидеть, как менялись возможности виртуальных машин на платформе VMware ESX/ESXi, и что теперь может ВМ на платформе vSphere 6.5:

На сайте проекта VMware Labs не так давно появилась очередная полезная утилита для администраторов vSphere - PowerCLI Core. Эта штука позволяет пользователям применять те же самые командлеты PowerCLI на системах Linux, Mac и Docker, которые ранее были доступны только для Windows.

PowerCLI Core использует компоненты Microsoft PowerShell Core и .Net Core.

PowerCLI Core предоставляет мультиплатформенный язык сценариев, который позволяет управлять инфраструктурой VMware vSphere практически с любой ОС. Скрипты PowerCLI, которые были написаны ранее только для Windows-версий фреймворка, теперь можно портировать на различные операционные системы и запустить эти сценарии в них без необходимости их изменения.

На данный момент фреймворк реализует более 280 командлетов, но касаются они только основных возможностей vCenter и ESXi, а также распределенного виртуального коммутатора (vDS). Модули для работы с хранилищами, лицензиями и VMware Update Manager пока не поддерживаются:

Также пока нет и поддержки других расширенных модулей:

Для развертывания и начала использования PowerCLI Core почитайте документ с инструкциями. Скачать PowerCLI Core можно по этой ссылке.

Как многие из вас знают, совсем недавно компания VMware сделала доступной для скачивания новую версию серверной платформы виртуализации VMware vSphere 6.5. Традиционно, с каждой новой версией происходит увеличение максимумов конфигурации различных компонентов платформы. Приведем их сравнение ниже:

Хосты VMware ESXi 6.5 и виртуальные машины:

Серверы vCenter:

И познавательная инфографика максимальных конфигураций платформы виртуализации ESX/ESXi от первой версии до 6.5 от virten.net (кликабельно):

Ну и, конечно, полезно посмотреть документ "Configuration Maximums vSphere 6.5", который был также обновлен с выходом новой версии платформы.

Не так давно мы писали о новых возможностях платформы VMware vSphere 6.5, о которых было объявлено в октябре этого года. Также мы писали о Site Recovery Manager 6.5, Virtual SAN 6.5, Virtual Volumes 2.0 и других продуктах линейки версий 6.5.

Ну а вчера компания VMware сделала эти и многие другие продукты доступными для загрузки.

Вот основные ссылки:

• VMware ESXi 6.5
• vCenter Server (Windows/VCSA) 6.5
• vSAN Witness Appliance 6.5
• vSphere Replication 6.5
• Site Recovery Manager 6.5
• vSphere Data Protection 6.1.3
• vRealize Log Insight 4.0
• vRealize Operations Manager 6.4
• vRealize Business for Cloud 7.2
• vSphere PowerCLI 6.5
• vSphere vMA 6.5
• vSphere CLI 6.5
• vSphere Management SDK 6.5
• vSphere Automation SDK for Java 6.5
• vSphere Automation SDK for .NET 6.5
• vSphere Automation SDK for REST 6.5
• vSphere Automation SDK for Python 6.5
• vSphere Automation SDK for Perl 6.5
• vSphere Automation SDK for Ruby 6.5
• vSAN Management SDK (.NET, Java, Ruby, Perl & Python ) 6.5
• Virtual Disk Development Kit (VDDK) 6.5
• vSphere Web Client SDK 6.5
• OVFTool 4.2

Отметим, что интерфейс PowerCLI версии 6.5 еще недоступен, но по ссылкам выше через некоторое время его можно будет скачать.

Также появилось несколько полезных документов по обновленным продуктам:

• Документация по vSphere 6.5
• vSphere 6.5 Configuration Maximums
• vSphere 6.5 (SOAP) API Reference Guide
• vSAN 6.5 API Reference Guide

Ну и ссылки на Release Notes к соответствующим продуктам (по SDK также ссылки пока не рабочие):

• vSphere / ESXi 6.5
• vSphere Client (HTML5) 6.5
• vSphere Update Manager 6.5
• Virtual SAN 6.5
• vSphere Replication 6.5
• vSphere Data Protection 6.1.3
• vRealize Log Insight 4.0
• vRealize Operations Manager 6.4
• vSphere PowerCLI 6.5
• vSphere vMA 6.5
• vSphere CLI 6.5
• vSphere Management SDK 6.5
• vSphere Web Services SDK 6.5
• vCenter Server Appliance Management API
• vSphere Automation SDK for Java 6.5
• vSphere Automation SDK for .NET 6.5
• vSphere Automation SDK for REST 6.5
• vSphere Automation SDK for Python 6.5
• vSphere Automation SDK for Perl 6.5
• vSphere Automation SDK for Ruby 6.5
• Virtual Disk Development Kit (VDDK) 6.5
• OVFTool 4.2

Интересно также взглянуть на график числа дней, которое потребовалось на выпуск новых версий VMware vSphere:

Как вы уже знаете, в новой версии платформы виртуализации VMware vSphere 6.5 появилось шифрование на уровне виртуальных машин, которое так давно запрашивали пользователи.

Устроено это шифрование ВМ на базе алгоритма AES-NI, а управление ключами происходит по стандарту KMIP 1.1. Когда операция ввода-вывода приходит на диск виртуальной машины - она сразу же шифруется "на лету", что обеспечивает полную безопасность при попытке несанкционированного доступа к данным.

Шифруются не только виртуальные диски, но и конфигурационные файлы VMX, файлы снапшотов и все прочие файловые объекты, относящиеся к виртуальной машине. Шифрованные виртуальные машины всегда перемещаются между хостами ESXi средствами также шифрованного vMotion.

Между тем, на уровне отказоустойчивого кластера хранилищ Virtual SAN также есть возможность шифрования их содержимого. Как же эти два вида шифрования соотносятся между собой, и зачем они оба нужны?

Для начала посмотрим, как это работает на примере схемы шифрования на уровне виртуальных машин:

VM Encryption реализован на уровне программного интерфейса VAIO (vSphere APIs for IO Filters), который позволяет специальному фильтру обрабатывать команды ввода-вывода непосредственно до того, как они поступят в виде блоков на устройство хранения (помимо шифрования, фильтры могут еще и некоторым другим образом обрабатывать ввод-вывод).

Непосредственно - это означает, перед тем как отправить конечную команду ввода-вывода на устройство, фреймворк VAIO проверяет, назначено ли шифрование для ВМ в политике хранения (Storage policy), и если это так - то команда процессится на уровень соответствующего I/O-фильтра, после чего сразу же отправляется на блочный девайс.

Таким образом, на самом нижнем уровне происходит шифрование ввода-вывода, и это очень безопасно. Зато не очень удобно - зашифрованные таким образом блоки, поступающие в пространство хранения VSAN теперь уже не могут быть эффективно дедуплицированы (малая вероятность совпадения блоков), а также и сжаты - ведь шифрованные данные обладают большой энтропией, а значит неэффективны для алгоритмов сжатия.

Поэтому в кластере VSAN, где на первом плане, как правило, эффективность хранения виртуальных машин в плане экономии дискового пространства, шифрование организуется иным образом. Тут используется концепция "encryption at rest". Сначала данные в незашифрованном виде идут по сети (в целях ускорения и работы сжатия), затем они в зашифрованном виде падают в кэш. После чего, перед тем, как отправиться на постоянное хранение (destaging), они будут расшифрованы, дедуплицированы/сжаты и снова зашифрованы уже на целевом устройстве.

Поэтому шифрование на уровне кластера VSAN - это настройка также на уровне всего кластера. Таким образом, ключевые отличия данных методов шифрования состоят в следующем:

• Шифрование уровня ВМ (VM Encryption) средствами VAIO:
  • Основано на политиках хранения (и включается для конкретной ВМ)
  • Передача данных также шифрована (vMotion)
  • Дедупликация на целевом хранилище неэффективна
• Шифрование уровня кластера хранилищ (vSAN Encryption):
  • Включается для всего кластера в целом
  • Данные передаются между хостами в незашифрованном виде, но в кэше хранятся шифрованными
  • Полная совместимость со всеми сервисами VSAN, такими как компрессия и дедупликация

Почти месяц назад мы писали об обновлении тонкого клиента VMware vSphere HTML5 Web Client 2.8, построенного на базе легковесной технологии HTML5. За это время компания VMware уже успела анонсировать новую версию платформы виртуализации VMware vSphere 6.5, которая выйдет до конца этого года, но в которой еще не будет полноценного HTML5 Client. Увы.

Однако VMware продолжает серьезными темпами наращивать функционал HTML5 Web Client - за месяц были выпущены обновления 2.9, 2.10, 2.11 и 2.12. Посмотрим что в них появилось нового:

• Конвертация и клонирование ВМ в шаблон (template) и обратно
• Создание датасторов NFS3 / NFS4.1, в том числе в режиме read-only
• Изменение политик Multipathing в разделе Host Storage Devices, а также просмотр деталей устройств и разделов
• Возможность перетащить ВМ через Drag and drop на хост, который имеет доступ к тому же хранилищу и сети
• Запуск мастера New Virtual Machine wizard из объекта vApp, хранилища или кластера хранилищ
• Показ активных фильтров в колонках гридов
• Возврат к предыдущим шагам мастера вызывает повторную валидацию следующих
• Подробная информация в разделе VMFS Datastore > Configure > Device Backing, включая тип устройства
• PCI-устройства теперь доступны для passthrough и выводятся их детали
• Mount/Unmount хранилищ VMFS
• Комбинации клавиш для операций с питанием ВМ
• Изменение настроек ВМ содержит опцию Tools Upgrade для операции включения
• Возможность удалить datacenter из inventory
• Функция Rescan storage (рескан томов VMFS и новых Storage Devices, включая iSCSI)
• Добавление и удаление таргетов Dynamic/Static Discovery Targets из настроек iSCSI-адаптера
• Удаление виртуального коммутатора
• Изменение настроек Lockdown mode
• Присоединение хостов ESXi к домену
• Редактирование general options в настройках ВМ
• Создание тэгов и новых глобальных категорий для тэгов, а также поиск по ним
• Валидация некорректного ввода Dynamic/Static discovery targets
• Добавление портгрупп к виртуальным коммутаторам
• Операции с VMware Tools для нескольких ВМ одновременно (install/upgrade, unmount)
• Улучшения производительности и исправление ошибок

Как мы видим, сделано, бесспорно, было много. Но и такого темпа, видимо, мало, чтобы сделать HTML5 Web Client полноценным до конца года, одновременно с доступностью vSphere 6.5. Скачать HTML5 Web Client 2.12 можно по этой ссылке.

Как мы недавно писали, скоро компания VMware сделает доступной для загрузки новую версию платформы виртуализации VMware vSphere 6.5, где будет немало новых возможностей. Одно из нововведений, о котором мы еще не упоминали - это новый подход к организации VMware Tools.

Мы уже рассказывали ранее, что теперь VMware Tools для основных гостевых ОС входят в состав ESXi, но остальные поставляются отдельно от дистрибутивов платформы, и их можно скачать отсюда. Стандартные VMware Tools, которые подходят для большинства ОС Windows и Linux можно обновлять через VMware Update Manager (VUM).

Следующие версии VMware Tools состоят из двух релизов - VMware Tools 10.1 и VMware Tools 10.0.12 (это два разных ISO-образа). Версия 10.1 - это развивающаяся ветка для современных гостевых систем, а 10.0.12 - замороженная, которая предназначена для устаревших ОС, которые уже не обновляются. То есть апгрейд с версии тулзов 10.0.9 будет на 10.1. Подробнее об этом рассказано в KB 2015161.

Вот как выглядит назначение VMware Tools в зависимости от версии:

Также в VMware Tools были сделаны улучшения в плане гранулярности при поддержке Linux-систем. Если раньше для CentOS тип гостевой ОС был CentOS 4/5/6/7, то в vSphere 6.5 системы CentOS с точки зрения VMware Tools разделены на CentOS 7, CentOS 6 и CentOS 4/5.

Также напомним, что многие Linux-дистрибутивы идут с интегрированной версией Open VM Tools, и к ним не относится описанное выше.

В vSphere Client можно посмотреть как версию VMware Tools 10.0.7, так и внутренний номер пакета (например, 10247). Там же есть информация и о типе установке тулзов - MSI, OSP, OVT или TAR Tools. В данном случае мы видим, что это Open VM Tools:

Также ISO-файлы VMware Tools теперь идут с файлами контрольных сумм, по которым можно проверить соответствие пакетов на аутентичность их происхождения за счет сверки хэшей. Поэтому надо быть внимательным при распаковке составляющих пакета, и ничего оттуда не убирать.

Сейчас Tools 8.x и 9.0.x (от vSphere 5.0 и 5.1, поддержка которых прекращена) еще будут напрямую обновляться до десятой версии, однако впоследствии нужно будет делать двухступенчатый апгрейд, поэтому лучше обновиться уже сейчас.

Ну и последняя, но важная штука - теперь для VMware Tools, начиная с версии 10.1, доступна подробная документация.

Скачать обновленные версии тулзов можно уже сейчас (не дожидаясь vSphere 6.5) по этим ссылкам:

• VMware Tools 10.1
• VMware Tools 10.0.12

Не так давно мы писали о новых возможностях платформы виртуализации VMware vSphere 6.5, где впервые появилась так давно запрашиваемая администраторами функция шифрования, как содержимого виртуальных дисков, так и шифрования горячих миграций vMotion.

Устроено это шифрование ВМ на базе алгоритма AES-NI, а управление ключами происходит по стандарту KMIP 1.1. Когда операция ввода-вывода приходит на диск виртуальной машины - она сразу же шифруется "на лету", что обеспечивает полную безопасность при попытке несанкционированного доступа к данным.

Шифруются не только виртуальные диски, но и конфигурационные файлы VMX, файлы снапшотов и все прочие файловые объекты, относящиеся к виртуальной машине.

Шифрование объектов ВМ идет за ее пределами, таким образом гостевая ОС не имеет доступа к ключам шифрования. Шифрованные виртуальные машины всегда перемещаются между хостами ESXi средствами также шифрованного vMotion.

Чтобы начать шифровать виртуальную машину, нужно назначить ей соответствующую политику хранения (Storage Policy):

Как работает VM Encryption в VMware vSphere 6.5:

• Пользователь назначает политику VM Encryption на уровне виртуальной машины.
• Для машины генерируется случайный ключ и шифруется ключом из key manager (KMS Key).
• При включении ВМ сервер vCenter получает ключ из Key Manager, посылает его в VM encryption Module на сервере ESXi, что разлочивает ключ в гипервизоре.
• Далее все операции ввода-вывода идут через encryption module, шифруя все входящие и исходящие SCSI-команды прозрачно для гостевой ОС.

Все это совместимо со сторонними системами управления ключами (и требует одну из них), которые построены на стандарте KMIP версии 1.1 или выше:

Для того, чтобы расшифровать виртуальную машину и хранить далее ее в обычном формате, нужно просто поставить дефолтную политику хранения (Datastore default).

Также будет специальный командлет PowerCLI, который может шифровать/расшифровывать ВМ, а также определять, какие из них в данный момент зашифрованы.

vCenter в системе шифрования работает только как клиент. Для управления ключами используется Key Management Server (KMS).

В механизме управления привилегиями теперь появилась роль No Cryptography Administrator. Если ее назначить, то стандартному администратору будут запрещены следующие привилегии:

• Manage key servers
• Manage keys
• Manage encryption policies
• Console access to encrypted VMs
• Upload/download encrypted VMs

В качестве KMS можно использовать любые внешние системы, работающие по стандарту KMIP:

При использовании шифрования ВМ нужно учитывать следующие моменты:

• Да, вам понадобится система управления ключами (внешний Key Management Server)
• Не поддерживаются возможности SAN Backup.
• Если для обычного метода бэкапа сделать резервную копию - она будет нешифрованной, если восстановить - то все будет в соответствии с политикой целевого хранилища (то есть, ВМ может оказаться незашифрованной после восстановления).
• Сам сервер vCenter не может быть зашифрован - иначе его просто было бы нельзя включить.
• Также не поддерживаются следующие возможности:
  • Suspend/resume
  • Шифрование ВМ со снапшотами и создание снапшотов для шифрованных ВМ
  • Serial/Parallel port
  • Content library
  • vSphere Replication

Для vMotion шифрование включается на уровне отдельной ВМ, а для передачи данных в момент синхронизации используются 256-битные ключи шифрования.

Есть 3 политики для шифрованного vMotion:

• Disabled - отключено.
• Opportunistic - шифрование только в случае, если это поддерживает источник и целевой хост ESXi, в противном случае vMotion будет нешифрованным.
• Required - обязательно будет использоваться.

Перенос машин между хостами осуществляется путем обмена одноразовыми ключами, которые генерируются и обслуживаются сервером vCenter (не KMS).

В целом, шифрование виртуальных машин и миграций vMotion - штука классная, но помните, что вам потребуется для организации этого процесса внешний KMS-сервер.

Некоторое время назад мы писали об утилите Extrasphere от русских разработчиков, которая позволяет делать бесплатный vMotion для бесплатных серверов VMware ESXi.

Коллеги продолжают работать над этим средством и на днях выпустили версию Extrasphere 2.0, где присутствует весьма интересная функциональность HotMirror. На этот раз она не бесплатна, а доступна на базе подписки за деньги.

Она предназначена для получения холодного резерва функционирующей виртуальной машины (что дает нулевое RPO) на том же самом или резервном сервере виртуализации ESXi 5.5 и старше. Допускается использование гипервизоров с бесплатными лицензиями (ESXi Free, он же vSphere Hypervisor).

Сама утилитка написана на Unity (я думал, что на нем только игры делают):

Ключевая особенность зеркалирования Extrasphere заключается в том, что зеркало для обновления своего состояния должно быть включено на том же сервере виртуализации, на котором расположен исходный виртуальный сервер. В процессе зеркалирования фактическое потребление зеркалом оперативной памяти и ресурсов ЦП весьма невысокое.

Для аварийного включения зеркала на отличном от исходного сервере виртуализации ESXi необходимо, чтобы версия исходной виртуальной машины им поддерживалась, а также, чтобы файлы конфигурации и данных зеркала были ему доступны. Это требует наличия общего хранилища виртуальных машин между серверами (в отличие от функций vMotion, например).

В случае отсутствия такового, локальное хранилище принимающего сервера может быть подключено как сетевое хранилище с помощью специального компонента Extrasphere Resharer.

Так как одна виртуальная машина не может быть зарегистрирована на двух серверах одновременно, на стороне принимающего сервера регистрируется виртуальная машина заместитель (имеющая окончание имени “stub”), чтобы в случае возникновения аварийной ситуации на исходном сервере виртуализации оставалась возможность совершить аварийное включение на резервном сервере.

Существует две стадии зеркалирования:

1. Режим синхронизации.
2. Синхронный режим.

Режим синхронизации, в рамках которого происходит первичный перенос данных, предшествует синхронному режиму. При достижении синхронного режима зеркало получает копию всех изменений совершаемых над данными исходной виртуальной машины, при этом исходная виртуальная машина не получит подтверждение завершения записи до тех пор, пока не завершится запись в обе виртуальные машины.

Текущую стадию, а так же срок истечения сертификата можно узнать в том числе из консоли зеркала. Для экономии ресурса ЦП статус зеркалирования в консоли зеркала не обновляется автоматически. Для получения актуальной информации необходимо в консоли зеркала нажать любую клавишу.

При выключении зеркала без остановки зеркалирования происходит накопление информации о модифицированных областях исходной машины (видимо, используется технология Changed Block Tracking). Данные из этих областей переносятся в зеркало сразу после его включения. Существует несколько причин, по которым зеркалирование может повторно оказаться в режиме синхронизации:

1. Откат к снимку состояния исходной виртуальной машины или зеркала.
2. Перезагрузка сервера виртуализации

После достижения зеркалом синхронного режима становится возможным запуск тестов зеркала без остановки зеркалирования. Тест зеркала – это отдельная виртуальная машина, которая является связанным с зеркалом клоном, причем связь с зеркалом осуществляется посредством нового или существующего снимка состояния зеркала.

Время жизни теста зеркала, а так же снимка состояния зеркала на котором он основан, задается пользователем. Таким образом, допускается хранение нескольких версий зеркала, однако не рекомендуется допускать большого их количества из соображений быстродействия зеркалирования.

Тест зеркала может быть запущен на исходном или любом другом гипервизоре при условии, что он обладает доступом к данным зеркала и версия исходной виртуальной машины им поддерживается.

Зеркалирование может быть остановлено прямой командой из приложения. В этом случае зеркало преобразуется в обычную выключенную виртуальную машину. Аварийное включение зеркала, произведенное с исходного сервера виртуализации, также останавливает зеркалирование.

После остановки, зеркалирование виртуального сервера может быть возобновлено введением актуального ключа, с помощью которого последний раз оно запускалось. Лицензия зеркалирования может быть продлена с помощью применения нового ключа активации.

При использовании утилиты Extrasphere с режимом HotMirror есть несколько важных моментов:

• Обновление или удаление vib-пакета на сервере всегда принудительно останавливает все текущие операции зеркалирования.
• После остановки зеркалирования на исходной виртуальной машине и зеркале могут остаться снимки состояний, в которых зеркалирование по прежнему включено. Откат к таким снимкам может привести к потере данных зеркалом, а в некоторых случаях к невозможности включения виртуальной машины. Для устранения подобной проблемы после отката к снимку необходимо вновь применить процедуру остановки зеркалирования или аварийное включение зеркала.
• Добавление нового виртуального диска или изменение его размера в исходной машине не применяется к зеркалу автоматически и может приостановить зеркалирование, после чего потребуется его принудительный перезапуск в новое зеркало.
• На некоторых версиях гипервизоров при включении/выключении зеркалирования может производиться кратковременное замораживание исполнения виртуальной машины.

Также в утилите Extrasphere есть возможность HotClone. HotClone – это такой бесплатный пробник зеркалирования, который производит зеркалирование до достижения синхронного режима, после чего применяет к нему процедуру аварийного включения. Это сделано для того, чтобы вы могли убедиться в работоспособности клонирования виртуального сервера перед покупкой функционала зеркалирования.

Со своей стороны мы порекомендуем ребятам улучшить визуал утилиты (смотрится по-деревенски), купить музыку для промо-ролика (а то там вотермарки слышны:), а также поместить на сайт несколько картинок, поясняющих процесс.

Скачать Extrasphere 2.0 можно по этой ссылке.

Как-то один из наших читателей спросил, как можно узнать, какие из хостов VMware ESXi в кластере используют данное виртуальное хранилище (датастор)? Ведь использовать они его могут не только для хранения виртуальных машин, исполняемых на нем, но и для хартбитов - то есть сигналов доступности VMware HA, передаваемых через лок-файлы на этих датасторах.

Для этой цели можно использовать утилиту vSphere On-disk Metadata Analyzer (VOMA), которая умеет проверять консистентность метаданных тома VMFS, а также покажет вам информацию о том, какие хосты ESXi его используют.

Для начала нужно узнать имя датастора в формате определения устройства. Посмотрим список имен устройств через esxcli:

esxcli storage vmfs extent list

Мы увидим вот такую картину:

В колонке Device name мы видим имя устройства - eui.5adcee56739fb3ea:1. Теперь с помощью VOMA проведем проверку этого девайса и выведем метаданные этого тома VMFS:

voma -m vmfs -f check -d /vmfs/devices/disks/eui.5adcee56739fb3ea:1

Если том не в порядке, то будет выведено вот такое сообщение:

Error: Missing LVM Magic. Disk doesn’t have a valid LVM Device Error: Failed to Initialize LVM Metadata

Ну а если все окей, то вот что мы получим:

Тут мы видим, что устройство (том VMFS/датастор) используется одним хостом с соответствующим MAC-адресом. Дальше уже дело техники найти этот хост ESXi.

Если вы хотите вывести результаты работы данной команды VOMA в файл, то можно использовать ключ -s:

voma -m vmfs -f check -d /vmfs/devices/disks/eui.5adcee56739fb3ea:1 -s /tmp/output.txt